Python Abstract Base Classes: การจัดการการใช้งานโปรโตคอล เทียบกับการออกแบบอินเทอร์เฟซ

ในโลกของการพัฒนาซอฟต์แวร์ การสร้างแอปพลิเคชันที่แข็งแกร่ง บำรุงรักษาง่าย และปรับขนาดได้คือเป้าหมายสูงสุด เมื่อโปรเจกต์ขยายตัวจากสคริปต์เล็กๆ ไปสู่ระบบที่ซับซ้อนซึ่งบริหารจัดการโดยทีมงานนานาชาติ ความต้องการโครงสร้างที่ชัดเจนและสัญญาที่คาดเดาได้จะมีความสำคัญอย่างยิ่ง เราจะแน่ใจได้อย่างไรว่าส่วนประกอบต่างๆ ซึ่งอาจเขียนโดยนักพัฒนาที่แตกต่างกันในเขตเวลาที่แตกต่างกัน สามารถทำงานร่วมกันได้อย่างราบรื่นและเชื่อถือได้? คำตอบอยู่ที่หลักการของ abstraction

Python ด้วยธรรมชาติที่มีความยืดหยุ่น มีปรัชญาที่โด่งดังสำหรับการทำ abstraction: "duck typing" หากวัตถุเดินเหมือนเป็ดและร้องเสียงเหมือนเป็ด เราก็ปฏิบัติต่อมันเหมือนเป็ด ความยืดหยุ่นนี้เป็นหนึ่งในจุดแข็งที่ยิ่งใหญ่ที่สุดของ Python ส่งเสริมการพัฒนาที่รวดเร็วและโค้ดที่อ่านง่าย แต่ในแอปพลิเคชันขนาดใหญ่ การพึ่งพาข้อตกลงโดยนัยเพียงอย่างเดียวอาจนำไปสู่ข้อผิดพลาดที่ซับซ้อนและความยุ่งยากในการบำรุงรักษา จะเกิดอะไรขึ้นเมื่อ "เป็ด" บินไม่ได้อย่างไม่คาดคิด? นี่คือจุดที่ Abstract Base Classes (ABCs) ของ Python เข้ามามีบทบาท โดยให้กลไกอันทรงพลังในการสร้างสัญญาที่เป็นทางการ โดยไม่สูญเสียจิตวิญญาณแบบไดนามิกของ Python

แต่ที่นี่มีความแตกต่างที่สำคัญและมักถูกเข้าใจผิด ABCs ใน Python ไม่ใช่เครื่องมือที่ใช้ได้กับทุกสถานการณ์ พวกเขารองรับสองปรัชญาการออกแบบซอฟต์แวร์ที่แตกต่างกันและทรงพลัง: การสร้าง อินเทอร์เฟซ ที่ชัดเจนและเป็นทางการซึ่งต้องการการสืบทอด และการกำหนด โปรโตคอล ที่ยืดหยุ่นซึ่งตรวจสอบความสามารถ การทำความเข้าใจความแตกต่างระหว่างแนวทางทั้งสองนี้—การออกแบบอินเทอร์เฟซเทียบกับการใช้งานโปรโตคอล—คือกุญแจสำคัญในการปลดล็อกศักยภาพสูงสุดของการออกแบบเชิงวัตถุใน Python และการเขียนโค้ดที่ทั้งยืดหยุ่นและปลอดภัย คู่มือนี้จะสำรวจทั้งสองปรัชญา พร้อมตัวอย่างที่ใช้งานได้จริงและคำแนะนำที่ชัดเจนสำหรับเมื่อควรใช้แต่ละแนวทางในโปรเจกต์ซอฟต์แวร์ระดับโลกของคุณ

หมายเหตุเกี่ยวกับการจัดรูปแบบ: เพื่อให้เป็นไปตามข้อจำกัดด้านการจัดรูปแบบเฉพาะ ตัวอย่างโค้ดในบทความนี้จะแสดงภายในแท็กข้อความมาตรฐานโดยใช้รูปแบบตัวหนาและตัวเอียง เราขอแนะนำให้คัดลอกไปยังโปรแกรมแก้ไขของคุณเพื่อให้อ่านได้ดีที่สุด

พื้นฐาน: Abstract Base Classes คืออะไรกันแน่?

ก่อนที่จะเจาะลึกถึงปรัชญาการออกแบบทั้งสองแบบ มาสร้างพื้นฐานที่มั่นคงกันก่อน Abstract Base Class คืออะไร? โดยพื้นฐานแล้ว ABC คือพิมพ์เขียวสำหรับคลาสอื่นๆ มันกำหนดชุดของเมธอดและคุณสมบัติที่คลาสย่อยที่สอดคล้องต้องนำไปใช้ มันคือวิธีการกล่าวว่า "คลาสใดก็ตามที่อ้างว่าเป็นส่วนหนึ่งของครอบครัวนี้จะต้องมีความสามารถเฉพาะเจาะจงเหล่านี้"

โมดูล `abc` ที่มีอยู่ใน Python มีเครื่องมือในการสร้าง ABC ส่วนประกอบหลักสองอย่างคือ:

• `ABC`: คลาสผู้ช่วยที่ใช้เป็น metaclass เพื่อสร้าง ABC ใน Python เวอร์ชันล่าสุด (3.4+) คุณสามารถสืบทอดจาก `abc.ABC` ได้โดยตรง
• `@abstractmethod`: decorator ที่ใช้เพื่อทำเครื่องหมายเมธอดว่าเป็น abstract คลาสย่อยใดๆ ของ ABC ต้องนำเมธอดเหล่านี้ไปใช้

มีกฎพื้นฐานสองข้อที่ควบคุม ABC:

1. คุณไม่สามารถสร้างอินสแตนซ์ของ ABC ที่มีเมธอด abstract ที่ยังไม่ได้นำไปใช้ได้ มันเป็นเทมเพลต ไม่ใช่ผลิตภัณฑ์สำเร็จรูป
2. คลาสย่อยที่เป็นรูปธรรมใดๆ ต้องนำเมธอด abstract ที่สืบทอดมาทั้งหมดไปใช้ หากล้มเหลว คลาสย่อยนั้นก็จะกลายเป็นคลาส abstract เช่นกัน และคุณไม่สามารถสร้างอินสแตนซ์ของมันได้

มาดูกันในทางปฏิบัติด้วยตัวอย่างคลาสสิก: ระบบสำหรับการจัดการไฟล์สื่อ

ตัวอย่าง: MediaFile ABC อย่างง่าย

ลองจินตนาการว่าเรากำลังสร้างแอปพลิเคชันที่ต้องจัดการไฟล์สื่อประเภทต่างๆ เรารู้ว่าไฟล์สื่อทุกไฟล์ ไม่ว่าจะอยู่ในรูปแบบใด ควรจะสามารถเล่นได้และมีข้อมูลเมตาบางอย่าง เราสามารถกำหนดสัญญานี้ด้วย ABC

import abc

class MediaFile(abc.ABC):
    def __init__(self, filepath: str):
        self.filepath = filepath
        print(f"Base init for {self.filepath}")
    @abc.abstractmethod
    def play(self) -> None:
        """Play the media file."""
        raise NotImplementedError
    @abc.abstractmethod
    def get_metadata(self) -> dict:
        """Return a dictionary of media metadata."""
        raise NotImplementedError

หากเราลองสร้างอินสแตนซ์ของ `MediaFile` โดยตรง Python จะหยุดเรา:

# This will raise a TypeError
# media = MediaFile("path/to/somefile.txt")
# TypeError: Can't instantiate abstract class MediaFile with abstract methods get_metadata, play

ในการใช้พิมพ์เขียวนี้ เราต้องสร้างคลาสย่อยที่เป็นรูปธรรมที่จัดเตรียมการใช้งานสำหรับ `play()` และ `get_metadata()`

class AudioFile(MediaFile):
    def play(self) -> None:
        print(f"Playing audio from {self.filepath}...")
    def get_metadata(self) -> dict:
        return {"codec": "mp3", "duration_seconds": 180}
class VideoFile(MediaFile):
    def play(self) -> None:
        print(f"Playing video from {self.filepath}...")
    def get_metadata(self) -> dict:
        return {"codec": "h264", "resolution": "1920x1080"}

ตอนนี้ เราสามารถสร้างอินสแตนซ์ของ `AudioFile` และ `VideoFile` ได้แล้ว เพราะพวกมันปฏิบัติตามสัญญาที่กำหนดโดย `MediaFile` นี่คือกลไกพื้นฐานของ ABCs แต่พลังที่แท้จริงมาจากการ วิธี ที่เราใช้กลไกนี้

ปรัชญาแรก: ABCs ในฐานะการออกแบบอินเทอร์เฟซที่เป็นทางการ (Nominal Typing)

วิธีแรกและเป็นแบบดั้งเดิมที่สุดในการใช้ ABCs คือการออกแบบอินเทอร์เฟซที่เป็นทางการ แนวทางนี้มีรากฐานมาจาก nominal typing ซึ่งเป็นแนวคิดที่คุ้นเคยสำหรับนักพัฒนาที่มาจากภาษาเช่น Java, C++ หรือ C# ในระบบที่เป็นชื่อ ประเภทความเข้ากันได้ถูกกำหนดโดยชื่อและการประกาศอย่างชัดแจ้ง ในบริบทนี้ คลาสจะถือว่าเป็น `MediaFile` ก็ต่อเมื่อสืบทอดโดยชัดแจ้ง จาก ABC ของ `MediaFile`

ลองนึกถึงการรับรองอย่างมืออาชีพ ในการเป็นผู้จัดการโครงการที่ได้รับการรับรอง คุณไม่สามารถแค่ทำตัวเหมือนผู้จัดการโครงการได้ คุณต้องศึกษา สอบผ่านข้อสอบเฉพาะ และได้รับใบรับรองอย่างเป็นทางการที่ระบุคุณสมบัติของคุณอย่างชัดเจน ชื่อและสายเลือดของการรับรองของคุณมีความสำคัญ

ในโมเดลนี้ ABC ทำหน้าที่เป็นสัญญาที่ไม่สามารถต่อรองได้ การสืบทอดจากมัน คลาสให้คำมั่นสัญญาอย่างเป็นทางการแก่ส่วนที่เหลือของระบบว่ามันจะจัดเตรียมฟังก์ชันการทำงานที่จำเป็น

ตัวอย่าง: กรอบการส่งออกข้อมูล

ลองจินตนาการว่าเรากำลังสร้างเฟรมเวิร์กที่อนุญาตให้ผู้ใช้ส่งออกข้อมูลในรูปแบบต่างๆ เราต้องการให้แน่ใจว่าปลั๊กอินส่งออกแต่ละรายการเป็นไปตามโครงสร้างที่เข้มงวด เราสามารถกำหนดอินเทอร์เฟซ `DataExporter` ได้

import abc
from datetime import datetime
class DataExporter(abc.ABC):
    """A formal interface for data exporting classes."""
    @abc.abstractmethod
    def export(self, data: list[dict]) -> str:
        """Exports data and returns a status message."""
        pass
    def get_timestamp(self) -> str:
        """A concrete helper method shared by all subclasses."""
        return datetime.utcnow().isoformat()
class CSVExporter(DataExporter):
    def export(self, data: list[dict]) -> str:
        filename = f"export_{self.get_timestamp()}.csv"
        print(f"Exporting {len(data)} rows to {filename}")
        # ... actual CSV writing logic ...
        return f"Successfully exported to {filename}"
class JSONExporter(DataExporter):
    def export(self, data: list[dict]) -> str:
        filename = f"export_{self.get_timestamp()}.json"
        print(f"Exporting {len(data)} records to {filename}")
        # ... actual JSON writing logic ...
        return f"Successfully exported to {filename}"

ที่นี่ `CSVExporter` และ `JSONExporter` เป็น `DataExporter` อย่างชัดเจนและตรวจสอบได้ ตรรกะหลักของแอปพลิเคชันของเราสามารถพึ่งพาสัญญานี้ได้อย่างปลอดภัย:

def run_export_process(exporter: DataExporter, data_to_export: list[dict]):
    print("--- Starting export process ---")
    if not isinstance(exporter, DataExporter):
        raise TypeError("Exporter must be a valid DataExporter implementation.")
    status = exporter.export(data_to_export)
    print(f"Process finished with status: {status}")
# Usage
data = [{"id": 1, "name": "Alice"}, {"id": 2, "name": "Bob"}]
run_export_process(CSVExporter(), data)
run_export_process(JSONExporter(), data)

สังเกตว่า ABC ยังมีเมธอดที่เป็นรูปธรรม `get_timestamp()` ซึ่งมีฟังก์ชันการทำงานร่วมกันให้กับคลาสย่อยทั้งหมด นี่เป็นรูปแบบที่พบบ่อยและทรงพลังในการออกแบบอินเทอร์เฟซ

ข้อดีและข้อเสียของแนวทางการออกแบบอินเทอร์เฟซอย่างเป็นทางการ

ข้อดี:

• ชัดเจนและไม่กำกวม: สัญญานั้นชัดเจนอย่างยิ่ง นักพัฒนาสามารถเห็นสายการสืบทอด `class CSVExporter(DataExporter):` และเข้าใจบทบาทและความสามารถของคลาสได้ทันที
• เป็นมิตรกับเครื่องมือ: IDE, linters และเครื่องมือวิเคราะห์แบบคงที่สามารถตรวจสอบสัญญาได้อย่างง่ายดาย ทำให้มีการเติมข้อความอัตโนมัติและการตรวจสอบข้อผิดพลาดที่ยอดเยี่ยม
• ฟังก์ชันการทำงานร่วมกัน: ABCs สามารถให้เมธอดที่เป็นรูปธรรม ทำหน้าที่เป็นคลาสพื้นฐานจริงและลดความซ้ำซ้อนของโค้ด
• ความคุ้นเคย: รูปแบบนี้เป็นที่จดจำได้ทันทีสำหรับนักพัฒนาจากภาษาเชิงวัตถุส่วนใหญ่

ข้อเสีย:

• การผูกที่แน่นหนา: คลาสที่เป็นรูปธรรมตอนนี้เชื่อมโยงโดยตรงกับ ABC หาก ABC จำเป็นต้องถูกย้ายหรือเปลี่ยนแปลง คลาสย่อยทั้งหมดจะได้รับผลกระทบ
• ความแข็งแกร่ง: บังคับให้มีความสัมพันธ์แบบลำดับชั้นที่เข้มงวด จะเป็นอย่างไรหากคลาสหนึ่งสามารถทำหน้าที่เป็น exporter ได้อย่างสมเหตุสมผล แต่สืบทอดมาจากคลาสพื้นฐานที่จำเป็นอื่นอยู่แล้ว? การสืบทอดหลายรายการของ Python สามารถแก้ปัญหานี้ได้ แต่ก็อาจนำมาซึ่งความซับซ้อนของตัวเอง (เช่น ปัญหา Diamond)
• การรุกล้ำ: ไม่สามารถใช้เพื่อปรับโค้ดของบุคคลที่สามได้ หากคุณกำลังใช้ไลบรารีที่จัดเตรียมคลาสที่มีเมธอด `export()` คุณไม่สามารถทำให้มันเป็น `DataExporter` ได้หากไม่สืบทอดจากมัน (ซึ่งอาจเป็นไปไม่ได้หรือไม่พึงปรารถนา)

ปรัชญาที่สอง: ABCs ในฐานะการใช้งานโปรโตคอล (Structural Typing)

ปรัชญาที่สอง ซึ่งมีความเป็น "Pythonic" มากขึ้น สอดคล้องกับ duck typing แนวทางนี้ใช้ structural typing ซึ่งความเข้ากันได้ถูกกำหนดโดยโครงสร้างและพฤติกรรม ไม่ใช่โดยชื่อหรือสายเลือด หากวัตถุมีเมธอดและแอตทริบิวต์ที่จำเป็นในการทำงาน วัตถุนั้นจะถือว่าเป็นประเภทที่เหมาะสมสำหรับงานนั้น โดยไม่คำนึงถึงลำดับชั้นคลาสที่ประกาศไว้

ลองนึกถึงความสามารถในการว่ายน้ำ ในการถูกพิจารณาว่าเป็นนักว่ายน้ำ คุณไม่จำเป็นต้องมีใบรับรองหรือเป็นส่วนหนึ่งของสายพันธุ์ "นักว่ายน้ำ" หากคุณสามารถเคลื่อนที่ผ่านน้ำได้โดยไม่จมน้ำ คุณก็คือ นักว่ายน้ำในเชิงโครงสร้าง คน สุนัข และเป็ด ทุกคนสามารถเป็นนักว่ายน้ำได้

ABCs สามารถใช้เพื่อทำให้แนวคิดนี้เป็นทางการได้ แทนที่จะบังคับการสืบทอด เราสามารถกำหนด ABC ที่รับรู้คลาสอื่นๆ เป็นคลาสย่อยเสมือนได้หากพวกมันนำโปรโตคอลที่จำเป็นไปใช้ สิ่งนี้ทำได้ผ่านเมธอดวิเศษพิเศษ: `__subclasshook__`

เมื่อคุณเรียก `isinstance(obj, MyABC)` หรือ `issubclass(SomeClass, MyABC)` Python จะตรวจสอบการสืบทอดอย่างชัดแจ้งก่อน หากล้มเหลว จะตรวจสอบว่า `MyABC` มีเมธอด `__subclasshook__` หรือไม่ หากมี Python จะเรียกมัน ถามว่า "นี่ คุณถือว่าคลาสนี้เป็นคลาสย่อยของคุณหรือไม่?" สิ่งนี้ช่วยให้ ABC กำหนดเกณฑ์การเป็นสมาชิกตามโครงสร้าง

ตัวอย่าง: โปรโตคอล `Serializable`

มานิยามโปรโตคอลสำหรับวัตถุที่สามารถแปลงเป็น dictionary ได้ เราไม่ต้องการบังคับให้วัตถุที่แปลงได้ทุกรายการในระบบของเราต้องสืบทอดจากคลาสพื้นฐานเดียวกัน พวกมันอาจเป็นโมเดลฐานข้อมูล, data transfer objects, หรือเพียงแค่คอนเทนเนอร์

import abc
class Serializable(abc.ABC):
    @abc.abstractmethod
    def to_dict(self) -> dict:
        pass
    @classmethod
    def __subclasshook__(cls, C):
        if cls is Serializable:
            # Check if 'to_dict' is in the method resolution order of C
            if any("to_dict" in B.__dict__ for B in C.__mro__):
                return True
        return NotImplemented

ตอนนี้ มาสร้างคลาสบางส่วน ที่สำคัญคือ จะไม่มีคลาสใดสืบทอดจาก `Serializable`

class User:
    def __init__(self, name: str, email: str):
        self.name = name
        self.email = email
    def to_dict(self) -> dict:
        return {"name": self.name, "email": self.email}
class Product:
    def __init__(self, sku: str, price: float):
        self.sku = sku
        self.price = price
    # This class does NOT conform to the protocol
class Configuration:
    def __init__(self, setting: str):
        self.setting = setting

มาตรวจสอบกับโปรโตคอลของเรา:

print(f"Is User serializable? {isinstance(User('Test', 't@t.com'), Serializable)}")
print(f"Is Product serializable? {isinstance(Product('T-1000', 99.99), Serializable)}")
print(f"Is Configuration serializable? {isinstance(Configuration('ON'), Serializable)}")
# Output:
# Is User serializable? True
# Is Product serializable? False <- Wait, why? Let's fix this.
# Is Configuration serializable? False

อ่า บั๊กที่น่าสนใจ! คลาส `Product` ของเราไม่มีเมธอด `to_dict` มาเพิ่มกัน

class Product:
    def __init__(self, sku: str, price: float):
        self.sku = sku
        self.price = price
    def to_dict(self) -> dict: # Adding the method
        return {"sku": self.sku, "price": self.price}
print(f"Is Product now serializable? {isinstance(Product('T-1000', 99.99), Serializable)}")
# Output:
# Is Product now serializable? True

แม้ว่า `User` และ `Product` จะไม่แชร์คลาสพื้นฐานร่วมกัน (นอกเหนือจาก `object`) ระบบของเราก็สามารถปฏิบัติต่อทั้งสองเป็น `Serializable` ได้ เพราะพวกมันทำให้โปรโตคอลสมบูรณ์ นี่เป็นเรื่องทรงพลังอย่างยิ่งสำหรับการถอดการเชื่อมโยง

ข้อดีและข้อเสียของแนวทางโปรโตคอล

ข้อดี:

• ความยืดหยุ่นสูงสุด: ส่งเสริมการผูกที่หลวมอย่างยิ่ง ส่วนประกอบสนใจเฉพาะพฤติกรรม ไม่ใช่สายการสืบทอดของการใช้งาน
• ความสามารถในการปรับตัว: เหมาะอย่างยิ่งสำหรับการปรับโค้ดที่มีอยู่ โดยเฉพาะอย่างยิ่งจากไลบรารีของบุคคลที่สาม ให้เข้ากับอินเทอร์เฟซของระบบของคุณโดยไม่ต้องแก้ไขโค้ดต้นฉบับ
• ส่งเสริมการประกอบ: ส่งเสริมรูปแบบการออกแบบที่วัตถุถูกสร้างขึ้นจากความสามารถที่เป็นอิสระ แทนที่จะผ่านต้นไม้การสืบทอดที่ลึกและแข็งกระด้าง

ข้อเสีย:

• สัญญาโดยนัย: ความสัมพันธ์ระหว่างคลาสและโปรโตคอลที่นำไปใช้ไม่ได้ปรากฏชัดเจนทันทีจากการนิยามคลาส นักพัฒนาอาจต้องค้นหาฐานโค้ดเพื่อทำความเข้าใจว่าเหตุใดอ็อบเจกต์ `User` จึงถูกปฏิบัติต่อเป็น `Serializable`
• ค่าใช้จ่ายขณะรันไทม์: การตรวจสอบ `isinstance` อาจช้าลงเนื่องจากต้องเรียก `__subclasshook__` และดำเนินการตรวจสอบเมธอดของคลาส
• ศักยภาพสำหรับความซับซ้อน: ตรรกะภายใน `__subclasshook__` อาจซับซ้อนพอสมควรหากโปรโตคอลเกี่ยวข้องกับเมธอด อาร์กิวเมนต์ หรือประเภทการคืนค่าหลายรายการ

การสังเคราะห์สมัยใหม่: `typing.Protocol` และการวิเคราะห์แบบคงที่

เมื่อการใช้งาน Python ในระบบขนาดใหญ่เติบโตขึ้น ความต้องการการวิเคราะห์แบบคงที่ที่ดีขึ้นก็เพิ่มขึ้น แนวทาง `__subclasshook__` นั้นทรงพลัง แต่เป็นเพียงกลไกขณะรันไทม์ จะเป็นอย่างไรถ้าเราสามารถได้รับประโยชน์จาก structural typing ก่อน ที่เราจะเรียกใช้โค้ด?

สิ่งนี้นำไปสู่การนำ `typing.Protocol` มาใช้ใน PEP 544 ซึ่งให้วิธีที่เป็นมาตรฐานและสง่างามในการกำหนดโปรโตคอลที่เน้นหลักสำหรับการตรวจสอบประเภทแบบคงที่ เช่น Mypy, Pyright หรือ inspector ของ PyCharm

คลาส `Protocol` ทำงานคล้ายกับตัวอย่าง `__subclasshook__` ของเรา แต่ไม่มี boilerplate คุณเพียงแค่นิยามเมธอดและลายเซ็นของพวกมัน คลาสใดๆ ที่มีเมธอดและลายเซ็นที่ตรงกันจะถือว่าเข้ากันได้เชิงโครงสร้างโดยตัวตรวจสอบประเภทแบบคงที่

ตัวอย่าง: โปรโตคอล `Quacker`

มาดูตัวอย่าง duck typing คลาสสิกอีกครั้ง แต่ใช้เครื่องมือสมัยใหม่

from typing import Protocol
class Quacker(Protocol):
    def quack(self, volume: int) -> str:
        """Produces a quacking sound."""
        ... # Note: The body of a protocol method is not needed
class Duck:
    def quack(self, volume: int) -> str:
        return f"QUACK! (at volume {volume})"
class Dog:
    def bark(self, volume: int) -> str:
        return f"WOOF! (at volume {volume})"
def make_sound(animal: Quacker):
    print(animal.quack(10))
make_sound(Duck()) # Static analysis passes
make_sound(Dog()) # Static analysis fails!

หากคุณเรียกใช้โค้ดนี้ผ่านตัวตรวจสอบประเภทเช่น Mypy มันจะทำเครื่องหมายบรรทัด `make_sound(Dog())` ด้วยข้อผิดพลาด: `Argument 1 to "make_sound" has incompatible type "Dog"; expected "Quacker"` ตัวตรวจสอบประเภทเข้าใจว่า `Dog` ไม่ทำให้โปรโตคอล `Quacker` สมบูรณ์เนื่องจากขาดเมธอด `quack` สิ่งนี้จะจับข้อผิดพลาดก่อนที่โค้ดจะถูกเรียกใช้

โปรโตคอลขณะรันไทม์พร้อม `@runtime_checkable`

โดยค่าเริ่มต้น `typing.Protocol` มีไว้สำหรับการวิเคราะห์แบบคงที่เท่านั้น หากคุณพยายามใช้ในการตรวจสอบ `isinstance` ขณะรันไทม์ คุณจะได้รับข้อผิดพลาด

# isinstance(Duck(), Quacker) # -> TypeError: Protocol 'Quacker' cannot be instantiated

อย่างไรก็ตาม คุณสามารถเชื่อมช่องว่างระหว่างการวิเคราะห์แบบคงที่และพฤติกรรมขณะรันไทม์ได้ด้วย decorator `@runtime_checkable` ซึ่งเป็นการบอก Python ให้สร้างตรรกะ `__subclasshook__` ให้คุณโดยอัตโนมัติ

from typing import Protocol, runtime_checkable
@runtime_checkable
class Quacker(Protocol):
    def quack(self, volume: int) -> str: ...
class Duck:
    def quack(self, volume: int) -> str: return "..."
print(f"Is Duck an instance of Quacker? {isinstance(Duck(), Quacker)}")
# Output:
# Is Duck an instance of Quacker? True

สิ่งนี้จะทำให้คุณได้รับประโยชน์ทั้งสองอย่าง: การนิยามโปรโตคอลที่ชัดเจนและประกาศสำหรับการวิเคราะห์แบบคงที่ และตัวเลือกสำหรับการตรวจสอบขณะรันไทม์เมื่อจำเป็น อย่างไรก็ตาม โปรดทราบว่าการตรวจสอบโปรโตคอลขณะรันไทม์นั้นช้ากว่าการเรียก `isinstance` มาตรฐาน ดังนั้นจึงควรใช้อย่างระมัดระวัง

การตัดสินใจเชิงปฏิบัติ: คู่มือนักพัฒนาทั่วโลก

ดังนั้น คุณควรเลือกแนวทางใด? คำตอบขึ้นอยู่กับกรณีการใช้งานเฉพาะของคุณ นี่คือคู่มือเชิงปฏิบัติที่อิงตามสถานการณ์ทั่วไปในโครงการซอฟต์แวร์ระดับนานาชาติ

สถานการณ์ที่ 1: การสร้างสถาปัตยกรรมปลั๊กอินสำหรับผลิตภัณฑ์ SaaS ทั่วโลก

คุณกำลังออกแบบระบบ (เช่น แพลตฟอร์ม e-commerce, CMS) ที่จะขยายโดยนักพัฒนาทั้งภายในและภายนอก ปลั๊กอินเหล่านี้จำเป็นต้องรวมเข้ากับแอปพลิเคชันหลักของคุณอย่างลึกซึ้ง

• คำแนะนำ: การออกแบบอินเทอร์เฟซอย่างเป็นทางการ (Nominal `abc.ABC`)
• เหตุผล: ความชัดเจน ความเสถียร และความชัดเจนมีความสำคัญอย่างยิ่ง คุณต้องการสัญญาที่ไม่สามารถต่อรองได้ที่นักพัฒนาปลั๊กอินต้องยอมรับโดยการสืบทอดจาก `BasePlugin` ABC ของคุณ สิ่งนี้ทำให้ API ของคุณไม่กำกวม คุณยังสามารถจัดเตรียมเมธอดผู้ช่วยที่จำเป็น (เช่น สำหรับการบันทึก, การเข้าถึงการกำหนดค่า, การทำให้เป็นสากล) ในคลาสพื้นฐาน ซึ่งเป็นประโยชน์อย่างมากสำหรับระบบนิเวศนักพัฒนาของคุณ

สถานการณ์ที่ 2: การประมวลผลข้อมูลทางการเงินจาก API ที่ไม่เกี่ยวข้องกันหลายรายการ

แอปพลิเคชันฟินเทคของคุณจำเป็นต้องบริโภคข้อมูลธุรกรรมจากเกตเวย์ชำระเงินทั่วโลกต่างๆ: Stripe, PayPal, Adyen และอาจรวมถึงผู้ให้บริการระดับภูมิภาคอย่าง Mercado Pago ในละตินอเมริกา อ็อบเจกต์ที่ส่งคืนจาก SDK ของพวกมันอยู่นอกเหนือการควบคุมของคุณโดยสิ้นเชิง

• คำแนะนำ: โปรโตคอล (`typing.Protocol`)
• เหตุผล: คุณไม่สามารถแก้ไขซอร์สโค้ดของ SDK ของบุคคลที่สามเหล่านี้เพื่อให้พวกมันสืบทอดจากคลาสพื้นฐาน `Transaction` ของเราได้ อย่างไรก็ตาม เรารู้ว่าอ็อบเจกต์ธุรกรรมแต่ละรายการมีเมธอดเช่น `get_id()`, `get_amount()` และ `get_currency()` แม้ว่าชื่ออาจจะแตกต่างกันเล็กน้อย คุณสามารถใช้รูปแบบ Adapter ร่วมกับ `TransactionProtocol` เพื่อสร้างมุมมองที่เป็นหนึ่งเดียว โปรโตคอลช่วยให้คุณกำหนด รูปร่าง ของข้อมูลที่คุณต้องการ ช่วยให้คุณเขียนตรรกะการประมวลผลที่ทำงานกับแหล่งข้อมูลใดๆ ตราบใดที่สามารถปรับให้เข้ากับโปรโตคอลได้

สถานการณ์ที่ 3: การปรับปรุงแอปพลิเคชัน Legacy ที่มี Monolithic ขนาดใหญ่

คุณได้รับมอบหมายให้แยก monolith แบบ legacy ออกเป็น microservices ที่ทันสมัย รหัสที่มีอยู่เป็นใยแมงมุมของการพึ่งพา และคุณจำเป็นต้องสร้างขอบเขตที่ชัดเจนโดยไม่ต้องเขียนใหม่ทั้งหมดในคราวเดียว

• คำแนะนำ: ผสมผสานกัน แต่เอนเอียงไปทาง Protocols อย่างมาก
• เหตุผล: Protocols เป็นเครื่องมือที่ยอดเยี่ยมสำหรับการปรับปรุงอย่างค่อยเป็นค่อยไป คุณสามารถเริ่มต้นด้วยการกำหนดอินเทอร์เฟซที่เหมาะสมที่สุดระหว่างบริการใหม่โดยใช้ `typing.Protocol` จากนั้น คุณสามารถเขียนอะแดปเตอร์สำหรับส่วนของ monolith เพื่อให้สอดคล้องกับโปรโตคอลเหล่านี้ได้โดยไม่ต้องแก้ไขโค้ด legacy หลักในทันที สิ่งนี้ช่วยให้คุณถอดการเชื่อมโยงส่วนประกอบได้อย่างค่อยเป็นค่อยไป เมื่อส่วนประกอบได้รับการถอดการเชื่อมโยงอย่างสมบูรณ์และสื่อสารผ่านโปรโตคอลเท่านั้น ก็พร้อมที่จะแยกออกมาเป็นบริการของตนเอง ABCs ที่เป็นทางการอาจถูกนำมาใช้ในภายหลังเพื่อกำหนดโมเดลหลักภายในบริการใหม่ที่สะอาด

บทสรุป: การถักทอ Abstraction เข้ากับโค้ดของคุณ

Abstract Base Classes ของ Python เป็นเครื่องพิสูจน์การออกแบบที่เน้นการปฏิบัติจริงของภาษา พวกมันจัดเตรียมชุดเครื่องมือที่ซับซ้อนสำหรับการทำ abstraction ซึ่งเคารพทั้งวินัยที่มีโครงสร้างของการเขียนโปรแกรมเชิงวัตถุแบบดั้งเดิมและศักยภาพแบบไดนามิกของการใช้ duck typing

การเดินทางจากข้อตกลงโดยนัยไปสู่สัญญาที่เป็นทางการเป็นสัญญาณของฐานโค้ดที่เติบโตขึ้น การทำความเข้าใจปรัชญาสองประการของ ABCs ช่วยให้คุณตัดสินใจด้านสถาปัตยกรรมอย่างมีข้อมูลที่นำไปสู่แอปพลิเคชันที่สะอาด บำรุงรักษาง่าย และปรับขนาดได้สูง

เพื่อสรุปประเด็นสำคัญ:

• การออกแบบอินเทอร์เฟซอย่างเป็นทางการ (Nominal Typing): ใช้ `abc.ABC` ด้วยการสืบทอดโดยตรงเมื่อคุณต้องการสัญญาที่ชัดเจน ไม่กำกวม และสามารถค้นพบได้ นี่เหมาะสำหรับเฟรมเวิร์ก ระบบปลั๊กอิน และสถานการณ์ที่คุณควบคุมลำดับชั้นคลาส มันเกี่ยวกับ คลาสคืออะไร โดยการประกาศ
• การใช้งานโปรโตคอล (Structural Typing): ใช้ `typing.Protocol` เมื่อคุณต้องการความยืดหยุ่น การถอดการเชื่อมโยง และความสามารถในการปรับโค้ดที่มีอยู่ สิ่งนี้สมบูรณ์แบบสำหรับการทำงานกับไลบรารีภายนอก การปรับปรุงระบบ legacy และการออกแบบเพื่อ behavioral polymorphism มันเกี่ยวกับ คลาสทำอะไรได้ โดยโครงสร้างของมัน

การเลือกระหว่างอินเทอร์เฟซหรือโปรโตคอลไม่ใช่แค่รายละเอียดทางเทคนิคเท่านั้น แต่เป็นการตัดสินใจออกแบบพื้นฐานที่จะกำหนดวิวัฒนาการของซอฟต์แวร์ของคุณ การเชี่ยวชาญทั้งสองอย่าง ช่วยให้คุณสามารถเขียนโค้ด Python ที่ไม่เพียงแต่ทรงพลังและมีประสิทธิภาพเท่านั้น แต่ยังสง่างามและทนทานต่อการเปลี่ยนแปลงอีกด้วย